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FOREWORD 


This  report  (Volume  I  through  Volume  VIII)  represents  the  final  phase  of 
a  study  and  test  which  was  initiated  in  September  1964  to  explore  newly  devel¬ 
oped  techniques  and  devices  for  presenting  T.  O.  (Technical  Order)  type  in¬ 
structions  and  information.  The  eight  volumes  of  data  contain  the  result  of  a 
test  conducted  in  an  operational  environment  using  concepts  developed  during 
an  earlier  phase  under  Contract  AF  04{694)-729  anu  documented  in  BSD-TR- 
65-456.  Both  the  early  phase  and  final  phases  which  were  accomplished  under 
Contract  AF  04(594) -984,  Project  1316,  ’’Presentation  of  Information  for  Mainte¬ 
nance  and  Operation  (PIMO)",  were  started  in  June  1966  and  completed  in 
April  1969.  This  final  report  was  submitted  in  May  1969. 

The  original  program  documentation  was  prepared  by  Mr.  C.  L.  Schaffer, 
3MTE,  in  1964.  He  subsequently  functioned  as  the  Air  Force  Program  Direc¬ 
tor  and  Chairman  of  a  V/orking  Group  which  monitored  all  development  through¬ 
out  the  life  of  the  project.  This  Group  was  composed  of  individuals  from  var¬ 
ious  Air  Force  commands  (AFLC,  MAC,  ATC,  ADC,  AFSC)  and  the  Army 
Command  (AMCPM,  AXMLE)  knowledgeable  in  the  various  maintenance  dis¬ 
ciplines  and  all  facets  of  the  T.  O.  system.  Capt.  Don  Tetemeyer,  the  Pro¬ 
ject  Scientist  during  the  formulative  stages  of  the  Program  was  largely  re¬ 
sponsible  for  the  basic  test  structure.  Mr.  John  Saunders  was  the  monitor 
for  all  contractual  aspects  until  his  reassignment  in  1968. 

Any  success  one  may  attribute  to  the  project  must  be  shared  by  numerous 
individuals;  however,  major  credit  and  appreciation  are  due  General  Howell  M. 
Estes,  Jr.,  Commander  of  the  Military  Airlift  Command,  who  provided  the 
C-141A  aircraft  and  the  bases  at  Charleston,  Dover  and  Norton  for  the  opera¬ 
tional  test.  Sharing  in  the  credit  for  the  MAC  contributions  are  Lt.  Col.  Don 
Watt  and  his  staff  at  Hq.  MAC,  and  Col.  Foreman,  Col.  Henzi,  W/O  Van  Riper 
and  all  the  personnel  at  Charleston  Air  Force  Base  and  also  at  Dover  and  Norton 
who  participated  in  the  test.  The  hardships  imposed  on  their  organizations 
are  recognized,  and  we  sincerely  appreciate  the  special  efforts  put  forth  to 
overcome  all  obstacles.  The  test  could  never  have  been  conducted  without  the 
cooperation  and  competent  performance  of  these  many  individuals. 

We  are  especially  indebted  to  the  Air  Force  Human  Resources  Laboratory, 
Wright -Patterson  Air  Force  Base  for  their  financial  contributions  at  a  critical 
point  in  the  project;  and  also  to  the  Army  Materiel  Command,  who  believed  the 
test  potential  of  sufficient  magnitude  to  warrant  the  expenditure  of  their  funds. 

We  are  most  grateful  for  their  confidence  and  assistance.  It  is  most  assuredly 
the  primary  factor  that  permitted  completion  of  the  test. 

This  technical  report  has  been  reviewed  and  is  approved. 

D.  A.  Cook,  Lt.  Col.  USAF 
Hq.  AFSC  (SCS-2) 


ABSTRACT 


This  report  describes  the  latest  phase  in  the  program  to  develop  and 
evaluate  PIMO  (Presentation  of  Information  for  Maintenance  and  Operation); 
a  job  guide  concept  applied  to  maintenance.  Between  August  1968  and  April 
1969,  a  test  was  conducted  at  Charleston  AFB,  South  Carolina,  to  deter¬ 
mine  the  effectiveness  of  PIMO.  Three  immediate  behavioral  effects  were 
expected:  1)  reduction  in  maintenance  time,  2)  reduction  in  maintenance 
errors,  and  3)  allow  usage  of  inexperienced  technicians  with  no  significant 
penalty.  Experienced  and  inexperienced  Air  Force  technicians  performed 
maintenance  on  C-141A  aircraft  using  PIMO  Job  Guides  presented  in  audio¬ 
visual  and  booklet  modes.  Performance  was  measured  in  terms  of  time  to 
perform  and  procedural  errors.  The  performance  was  compared  with  the 
performance  on  the  same  jobs  by  a  control  group,  i.e. ,  experienced  tech¬ 
nicians  performing  in  the  normal  manner.  The  following  conclusions  were 
drawn  from  the  test  results:  1)  after  initial  learning  trials,  both  experi¬ 
enced  and  inexperienced  technicians  using  PIMO  can  perform  error-free 
maintenance  within  the  same  time  as  experienced  technicians  performing 
in  the  normal  manner,  2)  inexperienced  technicians  perform  as  well  as 
experienced  technicians  when  both  use  PIMO,  3)  there  is  no  significant 
difference  between  audio-visual  and  booklet  modes,  4)  the  users  revealed 
an  overwhelmingly  positive  reaction  to  PIMO,  and  5)  the  performance  im¬ 
provements  provide  the  capabilities  to  significantly  improve  system  per¬ 
formance  defined  in  terms  of  departure  reliability,  time: -in-maintenance, 
and  operational  readiness.  This  report  also  presents  a  description  of  the 
recommended  operational  system,  specifications  and  guidelines  for  PIMO 
format  development,  including  troubleshooting. 
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PIMO  BASIC  technical  DATA  STORAGE  (BTDS)  program 


A.  INTRODUCTION 


A  true  test  of  a  techn.cal  data  management  system  is  the  degree  to 
which  the  data  reflect  the  details  of  the  system  which  it  supports. 

'iiiw  ..peed  and  compl  eteness  with  which  the  data  are  updated  to  reflect 
the  latest  equipment  configuration  and  maintenance  techniques  of  the 
system  are  two  of  the  most  important  criteria  of  data  management 
effectiveness. 


Notwithstanding  the  expenditure  of  considerable  resources,  there 
does  not  exist  in  the  armed  services  a  suitable  operational  technical 
data  configuration  control  system.  It  is  considerably  more  difficult 
to  control  the  needed  changes  to  the  technical  data  than  it  is  to  con¬ 
trol  hardware  changes.  One  hardware  change  precipitates  the  re¬ 
quirement  for  myriad  technical  data  changes.  For  example,  one 
change  to  any  aspect  of  the  Landing  gear  assembly  of  an  aircraft 
generates  requirements  for  changes  to  such  documents  as  mainte¬ 
nance  procedures,  parts  lists,  special  tools  lists,  supply  catalogs, 
etc.  Changes  to  maintenance  procedures  could  require  updating  of 
electrical,  structures,  or  hydraulic  sections  of  the  appropriate  mab.ie- 
nance  manuals. 


The  problems  of  managing  changes  to  technical  data  are  aggravated 
by  factors  which  transcend  those  of  the  sheer  size  of  the  data  base. 
The  different  methods  by  which  hardware,  hence  the  supporting 
technical  data,  are  acquired  by  the  services  add  to  the  complexities 
of  the  management  problem.  Control  of  the  technical  data  supporting 
system  hardware  procured  from  a  system  contractor  differs  from 
GFE  hardware  procurement  data  management  procedures. 


SECTION  I 
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Ae  a  part  of  the  PIMO  Phase  II  contract  for  the  Air  Force,  Serendipity, 
Inc.  focused  upon  the  problem  of  technical  data  updating.  Serendipity 
developed  the  Basic  Technical  Data  Storage  and  Retrieval  (BTOS)  Sys¬ 
tem  for  the  production  control  and  change  control  of  technical  data. 
(Technical  data  were  used  throughout  the  test  to  mean  maintenance  sup- 
port  data  such  as  maintenance  procedures,  IPB  data,  and  parts  listings) 
The  BTDS  is  an  integrated  group  of  computer  programs  used  to  identify 
technical  data  affected  by  changes  and  modifications  to  military  systems 

;2k. 

and  to  control  the  production  of  the  data  and  its  changes. 


Project  PIMO  had  as  its  major  goal  testing  the  concept  of  a  new  presen¬ 
tation  format  for  maintenance  data.  The  testing  of  this  format  called 
for  the  reformatting  and  control  of  a  set  of  maintenance  data.  Essentially, 
this  data  consisted  of  all  on-aircraft  maintenance  data  for  the  C-141A 
aircraft,  excluding  the  IPB  and  the  flight  manual.  The  BTDS  Program 
was  developed  in  order  to  ensure  the  timeliness  of  the  data  during  and 
after  its  production,  and  also  in  order  to  ensure  the  actual  production 
control  of  the  data  during  the  initial  reformatting  and  revision  phases. 


The  BTDS  was  made  up  of  two  sets  of  programs.  The  first  group  of 
programs  performed  the  configuration  control  function  of  the  Data  Con- 
trol  System,  thus  providing  the  vehicle  by  which  engineering  changes 
#ere  transformed  quickly  and  completely  into  technical  data  changes 
required.  A  second  group  of  programs  provided  for  the  production 
Status  control  of  the  maintenance  data  and  revisions  as  they  were  being 
produced.  A  discussion  of  each,  the  Configuration  Control  and  the  Fro 
duct{r,T»  Control  Programs  of  the  BTDS  follows. 
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CONFIGURATION  CONTROL  PROGRAMS 
A.  DESCRIPTION 

The  Configuration  Control  Programs  of  the  Basic  Technical  Data 
Storage  and  Retrieval  System  were  designed  for  the  storage  and 
recovery  of  information  pertinent  to  the  controlling  and  updating 
of  maintenance  data.  The  basic  program  represented  a  central 
depository  of  all  information  associated  with  the  content  of  the 
maintenance  data.  This  depository  was  In  the  form  of  a  digital 
computer  storage  program. 

A  user  language  conducts  the  interface  to  the  BTDS  so  that  data 
control  and  all  program  options  can  be  exercised  with  technical 
data  information,  but  without  requiring  programmers. 

The  BTDS  Programs  had  the  following  capabilities: 

1.  Storage  of  all  information  pertinent  to  the  development  of 
technical  data. 

t.  Acceptance  of  revisions  of  designated  data. 

3.  Retrieval  of  specified  data. 

4.  Retrieval  of  answers  to  specific  queries. 

The  BTDS  Program  was  written  in  COBOL  for  large  computer  sys¬ 
tems.  (See  Appendix  I  for  the  system  and  program  flowcharts.  )  The 
computer  language  provided  maximum  compatibility  with  computers 
other  than  the  ones  presently  being  used.  This,  of  course,  is  not  to 
imply  that  the  BTDS  Programs  would  operate  on  other  computers  at 
present,  but  that  the  program  was  appropriately  configured  to  be  con¬ 
verted  with  minimum  reprogramming. 
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The  BTDS  Configuration  Control  Programs  were  used  to  relate  digitally 
specific  source  and  reference  material  to  the  technical  data.  This  Infer 
ra&tien  was  stored  in  the  BTDS.  The  inputs  to  the  BTDS  were  those 
source  data,  drawings,  or  report*,  which  were  used  to  develop  the 
maintenance  procedures,  parts  lists,  special  tool  lists,  IPB.  The  pro- 
gramming  enabled  the  identification  of  all  data  (at  the  paragraph  and 
pap:  level)  which  would  be  affected  by  any  change  in  the  system  equip¬ 
ment.  Furthermore,  changes  in  maintenance  techniques  or  test  equip- 
meat  were  transferred  by  the  BTDS  into  change  requirements  for  the 
maintenance  data.  The  program  storage  and  retrieval  capability  used 
la  Project  PIMG  for  the  C-I41A  was  sufficiently  generic  to  be  equally 
applicable  to  missile  systems  cuch  as  ATLAS  and  SATURN.  to  large 
aircraft  systems,  and  to  ground  -based  equipment  such  as  tanks  and 
heavy  artillery*  as  well  as  to  complex  communication  systems. 


Figure  2-1  describes  the  prime  system  and  technical  support  data  j-  -■ 
duction  and  modification  interaction.  The  efficiency  of  the  maintenance 
system  was  determined  by  the  degree  to  which  the  maintenance  support 
data  represented  the  latest  prime  system  configuration.  The  changes  to 
the  operational  equipment  were  accomplished  through  modification  kits 
in  the  field.  The  modification  to  the  maintenance  data  occurred  through 

v 

either  complete  manual  revision,  change  notices  and/or  supplements. 
This  was  true  of  all  manuals  including  the  Illustrated  Parts  Breakdown 
and  associated  parts  listings  as  well  as  the  regular  maintenance  pro¬ 
cedure  manuals.  The  BTDS  Configuration  Control  was  a  vehicle  by 
whfc-it  these  technical  data  could  be  updated  to  represent  the  latest 
equipment  configuration. 


This  retrieval  capability  was,  of  course,  the  real  advantage  of  the 
system.  It  was  the  vehicle  by  which  specific  segments  of  the  mainte 
nance  support  data  were  identified  as  candidates  for  revision.  The 
only  input  required  for  this  identification  was  the  identification  of 
technical  order  changes,  engineering  drawing  changes,  end  item 
changer  and  part  number  changes.  For  Project  FIMO,  the  prime 
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source  material  was  the  C-141A  Technical  Orders,  and  these  technical 
order#  were  the  major  documentation  associated  with  the  PIMO  pro- 
eadires.  As  changes  occurred  to  technical  orders,  the  changed  para¬ 
graph  or  figure  number  was  used  to  interrogate  the  BTDS.  However, 
using  the  BTDS  in  the  development  of  the  initial  maintenance  data  for  a 
new  system,  the  prime  source  documentation  was  the  engineering  draw 
lags,  end  item,  end  part  numbers  associated  with  specific  portions  of 
the  maintenance  data. 

. 

RESULTS 


The  Basic  Technical  Data  Storage  and  Retrieval  System  has  been  opera¬ 
tionally  employed  for  the  past  two  years  by  Serendipity,  Inc.  cm  Project 
PIMO.  The  BTDS  has  more  than  met  expectations  in  the  area  of  con¬ 
trolling  and  updating  technical  data. 


The  BTDS  Programs  were  developed  with  sufficient  latitude  to  ensure 
their  use  as  the  primary  tool  for  the  initial  development  of  maintenance 
manuals  for  any  new  system.  The  following  is  a  brief  description  of 
some  of  the  outputs  and  uses  of  the  BTDS  during  Project  PIMO. 


The  method  used  in  storing  source  data  during  PIMO  provided  the  latitude 
of  associating  specific  material  in  the  maintenance  manual  with: 


1.  Technical  Orders,  Engineering  Reports,  Test  Procedures 


3.  SOP  {Standard  Operating  Procedure,  used  in  many  different 
maintenance  actions.) 


Special  test  equipment,  tools  and  parts 


S.  Applicable  IPB  figure  amber 


Figure  2-2  is  an  example  of  an  SOP  query.  The  SOP’s  were  developed 
in  ensure  that  Instructions  would  be  written  the  same  way  in  every 
maintenance  manual  section.* 


Figure  2-2  Sample  PTDS  Query  Printout  (SOP) 


The  query  request  started,  ’’Find  activities  related  to  SOP  Z-l".  Z-l 

. 

was  actually  a  procedure  for  preparation  for  Rear  Wing  Spar  maintenance 
and  parts  of  the  SOP  were  used  in  many  of  the  maintenance  actions  for 
flight  control#  and  structures.  The  results  were  that  the  BTDS  Identified 
14  unique  activities. 


During  the  source  data  documentation,  all  pages  of  each  activity  were 
coded  as  to  &e  content  of  the  illustration  shown.  This  coding  was  at 
the  removable  end  item  level  of  indenture.  This  coding  also  permitted 
the  identification  of  all  f  rames  of  every  activity  which  was  concerned 
with  a  removable  end  it«m. 

Figure  2-  3  shows  the  result  of  the  query,  ."What  activity  frames  are 
affected  ’toy  end  item  T06004  (IFF  Radar  Antenna)?1'  Four  activities 
are  listed.  If  the  existing  model  of  the  IFF  Radar  Antenna  were  re¬ 
placed  with  a  new  model  of  antenna,  this  query  would  result  in  the 
identification  of  maintenance  instructions  possibly  requiring  illustration 
changes  and  changes  in  maintenance  instructions  associated  with  that 
end  item. 


This  same  codtog  scheme  was  used  io  identify  subsystem  component 
references  when  an  engineering  change  affecting  a  subsystem  was  ap¬ 
proved  for  modification.  An  engineering  change  affecting  modifications 
to  the  HF-102  Communication  System  would  be  reviewed  to  determine 
the  end  items  undergoing  modification.  If  it  were  determined  that  all 
removable  items  in  the  HF  System  were  affected,  codes  representing 
those  end  items  Would  be  used  to  query  the  BTDS.  Figure  2-4  is  the 
result  of  that  query  and  the  printout  gives  six  different  maintenance 
activity  codes  Which  were  affected  by  modification  of  this  system.  AU 
reference  to  the  system  within  the  maintenance  manuals  could  then  be 
updated  according  to  the  engineering  change. 


Tools,  suppUfcs  and  test  equipment  were  alto  coded  against  each  frame 
calling  out  tfes  equipment.  Figure  2-5  is  a  printout  of  the  results  of  a 
query  on  aliphatic  naptha,  a  cleaning  solvent.  The  printout  lists  18 
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Figure  2-3  Sample  BTDS  Query  Printout 
(End  Item,  Activity  Frames) 
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Figure  a -4  Sample  BTDS  Query  Printout 
{End  Item*.  Activity  Codes) 


CJERY— FIIIS  ACODII  RELATED  TO  TTYPS«S8S  fSO*TT-»-©$  ?MAK*-ALf PHAT I C 


ACODE  -  1010009400  MO  OP  APRECYED  FRAMES  19  ACTIVITY 
AC  ODE  -  1 000000490  90  OF  AFFECTED  FRAMES  IN  ACTIVITY 
ACODE  »  1 930000490  MO  OT  ATTESTED  FRAMES  IM  ACTIVITY 
ACODE  -  1040000409  MO  Of  ATTECTS9  FRAMES  IN  ACTIVITY 
ACODE  *  LOft 91 38400  NO  OT  AFFECTED  FRAMES  IM  ACTIVITY 
ACODE  *  L0601 00400  MO  OP  AFFECTED  FRAMES  IM  ACTIVITY 
ACODE  -  B 81 680400  MHO  OF  AFFECTED  FRAMES  IM  ACTIVITY 
ACODE  «  B 086560400  MO  OF  AFFECTED  FRAMES  fM  ACTIVITY 

mom  >  sob oaooioo  m  of  affected  frames  in  activity 

ACODE  a  50800B04QG  MO  OF  AFFECTED  FRAMES  IM  ACTIVITY 
ACODE  a  S 080030490  MO  OF  AFFECTED  FRAMES  19  ACTIVITY 
ACODE  «  5060000591  90  OF  AFFECTED  FRAMES  IK  ACTIVITY 
ACODE  a  5060080400  MO  OF  AFFECTED  FRAMES  IM  ACTIVITY 
ACODE  »  S 0606 50400  MO  OF  AFFECTED  FRAMES  IM  ACTIVITY 
ACODE  a  TQ60008S0!  NO  OF  AFFECTED  FRAMES  IM  ACTIVITY 
ACODE  a  U8000 10400  MO  OF  AFFECTED  FRAMES  IN  ACTIVITY 
ACODE  -  V0809S0400  HO  OF  AFFECTED  FRANKS  IN  ACTIVITY 
ACODE  a  X070060100  NC  OF  AFFECTED  FRAMES  IN  ACTIVITY 


QUERY  REQUEST  COFtflXTE 


Figure  2-5  Sample  BTDS  Query  Printout  (Supplies) 
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activities  using  the  solution.  If  all  references  to  the  solvent  required 
modification  c*  the  solvent  were  to  be  replaced  with  a  different  type, 

the  BTDS  could  be  used  to  identify  each  and  every  page  of  the  mainte- 

*  Sc  ■  ■ 

nance  data  which  called  out  aliphatic  naptha.  This  assured  that  all  the 
material  which  might  be  affected  was  identified  in  a  matter  of  moments. 

Test  equipment  used  in  a  system  maintenance  also  undergoes  changes. 
The  BTDS  documentation  allowed  all  references  to  special  test  equip¬ 
ment  to  be  printed  out,  giving  the  test  equipment  number.  Figure  2-6 

. 

lists  14  maintenance  activities  which  were  affected  by  the  tester.  Model 
L10.  A  xurther  advantage  of  this  test  equipment  inventory  system  of 
the  BTDS  was  that  this  information  detailing  the  various  references  to 
specific  test  equipment  could  be  used  with  maintenance  action  frequency 
of  occurrence  data,  allowing  the  suppliers  of  this  equipment  to  approxi¬ 
mate  the  quantity  and  type  of  test  equipment  allocation  to  each  user 
location. 

Each  of  the  Remove  and  Install  activities  referenced  an  applicable  IPB 
source  for  the  removable  item.  With  this  information  documented  in 
the  BTDS,  one  could  identify  all  Remove  ard  Install  activities  associated 
«!th  uuy  particular  IPB  figure  number.  Figure  2-7  is  such  a  query, 
asking  for  all  activities  applicable  to  Figures  5-64  and  5-65  of  Techni¬ 
cal  Manual  T.O.  1C-141A-4(IPB).  Two  activities  were  affected  by  the 
first  figure,  and  three  by  the  second.  Any  change  to  an  IPB  figure  could 
easily  be  translated  to  activity  candidates  for  change. 

The  above  samples  of  the  BTDS  output  serve  to  indicate  some  of  the  ways 
In  which  the  BTDS  Program  can  be  used  as  a  technical  data  management 
system.  The  program  itself  would  most  benefit  a  technical  data  manage¬ 
ment  system  at  the  earliest  development  of  the  technical  data,  when  any 
system  is  undergoing  its  most  severe  design  changes.  The  source  data 
would  then  become  engineering  drawings,  engineering  reports,  etc. 

The  effects  of  engineering  changes  and  changes  to  the  engineering  data 
On  the  maintenance  manuals  could  be  readily  and  completely  deU  "mined. 
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MJERY— FIND  AC ODES  RELATED  TO  TTYPff*CSO  TN0-663S-55G-6496  TRARS«TESTER 

MODEL  tlO 


hCODE  «*  0080000600  NO  Of  AITKTB  FRAMES  IN  ACTIVITY  *  03 

ACODC  -  0090000190  NO  Of  AFFECTED  FRAMES  IN  ACTIVITY  •  06 

rC ODE  «  0060073400  NO  GP  AFFECTED  FRAMES  IN  ACTIVITY  •  08 

AC  ODE  -  0060099490  NO  OF  AFFECTED  FRAMES  IN  ACTIVITY  *  08 

r.CODE  *  0060100400  NO  OP  AFFECTED  FRAMES  IN  ACTIVITY  •  080 

ACODE  -  0066570400  NO  OP  APPSCTEN  FRANK#  IN  ACTIVITY  ■  08 

ACODE  ■  0080000600  HO  OP  AFFECTED  FRAMES  IN  ACTIVITY  •  07 

ACODE  -  0090010100  NO  OP  AFFECTED  FRAMES  IS  ACTIVITY  -  08 

ACODE  -  0080030100  90  OF  AFFECTED  FRAMES  IN  ACTIVITY  •  03 

ACODE  -  0090010600  NO  OP  AFFECTED  FRAMES  IN  ACTIVITY  •  OS 

ACODE  »  0090080600  NO  OP  AFFECTED  FRAMES  IN  ACTIVITY  «  03 

ACODE  -  0096396180  NO  OP  AFFECTED  FRAMES  IN  ACTIVITY  «  03 

ACODE  «  0900013109  NO  OF  AFFECTED  FRAMES  IN  ACTIVITY  »  08 

ACODE  •  BO*  00501 00  HO  OP  AFFECTED  FRAMES  IN  ACTIVITY  »  04 


Figure  2-6  Sample  BTDS  Query  Printout  (Test  Equipment) 


Figure  2-7  Sample  3TDS  Query  Printout  (IPB) 


PROCEDURES 

The  BTDS  Program  was  the  tool  lor  updating  maintenance  procedure 
source  data.  In  order  for  the  system  to  have  the  capability  for  an 
efficient  and  fast  update  to  the  maintenance  procedures,  the  BTDS  was 
programmed  to  store  information  for  „ach  maintenance  segment.  A 
maintenance  segment  is  that  portion  of  the  maintenance  data  which  rep¬ 
resents  the  data  peculiar  to  some  maintenance  action  or  descriptive 
of  a  particular  functionally  related  group  of  hardware  (subsystem),an 
individual  end  item,  or  group  of  ond  items. 

Examples  of  maintenance  segments  are  the  following: 

"Bench  checkout  procedures  for  the  VHF  Navigation  System", 

"Adjustment  of  the  Engine  Fuel  Control  System", 


"Removal  of  the  Fuel  Control  Unit",  and 

"Illustrated  Parts  Breakdown  of  the  Rudder  Power  Control". 


Each  segment  had  a  unique  activity  code  to  locate  it  in  the  BTDS  and 
each  was  documented  with  the  following  information  at  the  page  (or,  if 
preferred,  paragraph  level)  via  a  BTDS  input  form  called  Maintenance 
Activ'ty  Data  (MAD)  sheet: 

1.  Applicable  end  items  identification, 

2.  Source  data, 

3.  Applicable  IPB, 

4.  Applicable  special  lools  oi  test  equipment,  and 

5.  Applicable  part  numbers. 


a.  Erd  Item  Identification.  All  pictorial  source  data  were 


associated  with  the  maintenance  segment  and  page.  The  pictorial 


coding  system  allowed  the  interrogation  of  the  BTDS  for  pages 
(and  maintenance  segments)  affected  by  an  end  item  change. 

' f  t  j£3-  s- ;  *  -  ‘  ' 

b.  Source  Data  (Drawing*  and  Reports).  All  textual  source  data 
used  in  the  ct^velopmin^  of  the  maintenance  segment  was  coded  on  the 
Maintenance  Activity  Data  Sheet  form  by  engineering  drawing  or  report 

"bi£r3- 

number,  revision  date,  and,  if  applicable,  paragraph  number  or  sheet 
number. 

ijlg#  ' 

c.  Applicable  IPB.  For  all  types  of  maintenance  data  except  Illus¬ 
trated  Paris  Ereakriown,  the  applicable  IPB  Technical  Manual  number 
revision  date  and  figure  numbers  were  coded  against  the  maintenance 
segment.  This  IPB  source  was  that  figure  number  which  illustrated 
the  applicable  maintenance  segment  end  item  and  included  the  part 
numb-r  listing.  This  allowed  cross-referencing  between  the  parts 
breakdown  used  by  supply  and  the  maintenance  procedural  data  used 

by  :Ve  technician. 

s  >■ 

d.  Special  Tools  and  Test  Equipment.  For  each  activity,  special 
tools  and  test  equipment  were  coded  by  name  and  number  and  associated 
with  those  pages  within  the  maintenance  segment  which  called  out  their 


a.  End  Item  Part  Number.  The  end  item  part  number  or  numbers 
for  the  end  item  involved  in  the  maintenance  segment  were  listed 
against  the  pages  upon  which  procedures  or  descriptions  appeared 

against  the  end  item.  In  the  case  of  s  single  end  item  used  on  all  of 

* 

the  system  units,  a  single  end  item  part  number  was  listed  with  a 
"Usable  On  Code"  of  ALL.  If  more  than  one  part  number  was  applicable 
for  an  end  item,  each  part  number  was  listed  against  those  pages  which 
include  procedures  upon  that  end  item.  Tf  the  part  number  was  usable 

£  ' 

on  only  a  certain  modification  of  equipment,  then  a  "Usable  On  Code" 
(HOC)  was  assigned  and  coded  against  the  end  item  in  the  BTDS 


■■■ 


The  Maintenance  Activity  Dependency  Sheet  for  each  maintenance  seg¬ 
ment  was  inserted  via  the  keypunch  into  the  BTDS  storage  system.  This 

MADS  form  identified  for  each  PIMO  maintenance  segment:  1)  the  scarce 

. 

data  from  which  that  segment  wac  taken,  2)  the  end  item  part  number, 

. 

and  3)  special  tool  numbers  used  in  the  reformatted  maintenance  pro- 


The  BTDS  also  accepted  all  inquiries  listing  source  data  changes.  Th« 
inquiries  were  keypunched  and  entered  into  the  BTDS  Program.  The 
results  of  these  inquiries  were  printouts  listing,  for  each  query,  the 
name  and  maintenance  segment  code  of  each  maintenance  instructions! 
page  affected  by  the  change. 


USER  LANGUAGE 


INTRODUCTION 


The  BTBtf  user  language  was  specifically  designed  to  satisfy  the  manage 
mmt  need*  of  a  technical  data  management  system  by  giving  control  of 
tfie  storing  and  modification  of  data  and  the  direction  of  inquiries  to  the 
eae?  via  the  language.  Using  BTDS  language,  the  user  could  define  his 
*>-  using  &  statement  or  series  of  statements.  A  free -form  method 
of  data  input,  BTDS --0 -GRAM  was  employed  to  facilitate  keypunching. 
This  form  was  utilised  for  all  computer  request  statements  except 
STORE,  wh&oh  was  an  integral  part  of  the  Maintenance  Activity  Data 
Sheet  (MADS),  Figure  3-1. 


The  following  symbols  are  part  of  the  BTDS  language 


The  equal  sign  separates  the  parameter  designator  from 
th*  parameter  names  or  control  word. 


The  comma  separates  the  parameter  names  and  values 


(  The  left  parenthesis  begins  a  field  with  one  type  of 
information. 


)  The  right  parenthesis  ends  a  field  with  one  type  of 
information. 


Basic  technical  data  reference  information  was  stored  in  the  BTDS  files 
Tfa  the  Maintenance  Activity  Data  Sheet  (MADS)  under  the  command 
STORE  (AWS).  The  command  was  included  on  the  MADS  input  form; 
thus,  the  data  were  ready  for  BTDS  Control  once  the  M  ADS  form  was 
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Figure  8-4  Maintenance  Activity  Data  Sheet 
(MADS) 
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Each  activity  segment  was  defined  in  the  end -item -by-function  matrix. 
This  matrix  was  essentially  a  maintenance  requirement  list  giving  the 
procedure  to  be  developed.  The  matrix  listed  C-141A  end  items /sys¬ 
tems  and  the  maintenance  functions  (e.g. ,  Remove,  Install,  Operational 
Checkout  procedures)  supplied  for  the  system  or  end  item.  Figure  3-2 
shows  a  sample  page  from  this  matrix.  The  end  item  or  system  group 

had  a  unique  alpha-numeric  six-digit  code.  This  cole  along  with  the 

. 

function  code  (at  the  top)  gave  a  ten-digit  code  for  that  maintenance 
segment.  This  code  was  the  basic  identifier  of  each  individual  activity 
(maintenance  segment)  documented  in  the  BTDS. 


The  MAOS,  whether  referring  to  a  maintenance  action  or  a  system 
operational  description,  contained  basic  data  related  to  the  maintenance 


data.  These  data  were  sources  of  information  used  In  the  BTDS.  The 


MAOS  was  used  as  a  keypunch  form  and  therefore  had  a  strict  format, 


ENTRIES 


in  the  upper  right-hand  portion  of  the  form  shows  how  to  write  letters 
and  number  a.  •: 


ANALYST 


Initials  of  the  writer  who  develops  the  maintenance 
data. 


ADATE 


The  date,  written  in  the  order  shown,  when  the 
activity  is  completed. 


The  revision  number. 


A  CODE 


The  activity  code  which  identifies  the  particular 
maintenance  segment  (activity).  The  code  is  a 
ten-digit  alpha-numerical  number.  The  first 
six -digits  identify  the  end  item  piece  of  equip¬ 
ment;  the  next  four,  the  type  of  maintenance  data 
being  performed.  This  code  number  may  be  ob¬ 
tained  from  the  end  item  by  function  matrix. 
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Following  is  a  brief  description  of  each  entry  on  the  sheet.  The  block 
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$•4  Sample  Page  of  Function  by  End -Item  Matrix 


ANAME 


ENAME 


FRAME 

through 

NEPNG 


WUC 


INCA 


ETADU 


STYPE 


Assigned  Activity  Name.  This  is  restricted  to  50 
characters  including  spaces.  To  save  character 
space,  abbreviations  will  be  used  for  common 
function  names. 


Indicates  where  activity  is  performed. 


End  item  or  system  name  (same  as  in  the  activity 
name)  restricted  to  30  characters  and  spaces. 


These  are  quantity  counts  of  the  remainder  of  the 

•  . 


items  on  the  form.  They  should  all  be  filled  (with 
zeros  where  appropriate).  All  following  entries 
on  the  MADS  are  numbered  so  that  the  quantity  can 
be  obtained  directly  from  the  last  entry  made. 


Enter  all  work  unit  codes  which  are  applicable  to 
this  activity.  These  can  be  obtained  from  the  Work 
Unit  Code  Manual. 


Incorporated  activities.  If  another  activity  is  ref¬ 
erenced  anywhere  within  the  activity,  the  activity 
code  for  that  activity  is  entered  here. 


Equipment  this  activity  depends  upon.  Enter  the 
equipment  part  number  for  any  equipment  items 
which  are  affected  while  performing  this  activity. 
This  is  necessary  since  a  change  in  that  equip*' 
ment  might  change  the  performance  of  this  activity. 


Type  of  source  document.  Type  codes  are  as  follows: 
TOP  --  Technical  Order  Paragraph 
TOF  --  Technical  Order  Figure 
IPB  --  Illustrated  Parts  Breakdown 
EDO  --  Engineering  Document.  Includes  drawings, 
specifications,  reports,  etc. 
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The  source  number  is  the  engineering  document 
number,  drawing,  report,  etc. ,  just  as  it  is 
written  on  the  document. 


PSTART 


This  entry  provides  the  identifier  for  the  portion 
of  the  source  document  used  for  a  specific  page 
(frame)  of  maintenance  data.  The  ten  spaces 
allotted  on  the  MADS  are  broken  into  groups  of 
three,  four,  two  and  one  (in  that  order)  for  coding 


This  entry  provides  the  identifier  for  the  portion 
of  the  source  document  that  along  with  the  PSTART 
entry  includes  the  total  portion  of  that  document 
which  was  used  as  the  source  entry. 


PEND 


The  next  column  is  headed  NO.  This  entry  is  the 
total  number  of  frames  to  which  this  source  ref¬ 
erence  applies  (greater  than  IT  if  the  listed  frames 
take  more  than  one  line).  Following  that  is  listed 
the  page  number  to  which  this  scurce  reference 
applies. 


REFERENCED 

FRAMES 

(PAGES) 


A  code  specifying  the  type  of  tool  used.  Type  codes 
are  as  follows: 


STL  —  Special  tools  (e.g. ,  torque  wrench,  bearing 
removal  kit). 

CEQ  --Checkout  Equipment  (e.g.,  signal  generator, 
multimeter  and  other  test  equipment), 

SEQ  --  Support  equipment  including  expendable  sup¬ 
plies,  spares,  local  manufactured  items, 
aerospace. ground  equipment  (AGE),  and 
ground -handling  equipment. 


Identifying  number  for  the  referenced  tool  equip 
ment  or  supply  item. 


TNAMfi' 


Tool  name,  limited  to  30  characters  arc.  spaces. 
The  quantity  of  frames  oa  which  this  "tool''  is 
mentioned  iR  entered  under  NO,  followed  by  the 
number  of  the  frames  cm  which  it  is  used. 


Usable -On -Cole  that  specifies  model  to  which  this 
activity  pertains. 


Equipment  part  numbers  associated  with  this  activity. 

You  may  find  that  the  end  item  has  several  part 

,  ■■ 

numbers.  Each  part  number  will  be  listed  on  the 
same  line  as  the  Usable-On-Ccde  which  applies 
to  that  part  number*  If  particular  frames  apply 
to  different  Usable-On-Codes  or  part  numbers, 
these  will  be  listed  under  Referenced  Frames. 


EPNO 


A  summation  of  the  fore  going  description  appears  in  Table  I 


In  response  to  the  command  STORE  (AWS),  the  BTDS  Program  general 
a  printed  image  of  the  W  ADS  input  form  as  stored  in  the  data  files.  Ex 
amples  are  shown  in  Figure  3-3. 


D.  PRINTING  MAINTENANCE  ACTIVITY  DATA 


A  complete  log  of  all  MADS  forms  was  maintained  by  BTDS  Control  and 
was  available  for  reference.  When  additional  copies  of  MADS  infor¬ 
mation  were  required,  they  were  generated  by  the  command 


(AWS)  (ACODE  »  X) 


where  the  parameter  "X"  is  any  10-digit  activity  code.  In  response  to 
this  command,  the  BTDS  Program  generated  a  printed  image  of  the 
MADS  input  form. 


Examples  of  PRINT  requests  and  computer  responses  are  shown  in 
Figures  3-4  and  3-5. 
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Figure  3-3  Sample  Computer  Output  of  MADS  Input  Data 
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Fl^ar*  t«*4  Sample  PRINT  Requeet 


figure  3-r>  Sample  Computer  Output  of  PRINT  Request 
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/DELETING  DATA 
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Changes  to  the  basic  technical  data  were  accomplished  by  deleting  the 
old  data  and  entering  *ihe  new  data.  Deletions  were  restricted  to  an 
-a  activity;  therefore,  for  any  change  or  deletion  of  data  on  an  ac¬ 


tivity,  all  informatiovs  on  the  Maintenance  Activity  Data  Sheet  (MADS) 

- '  §L?  -  V.- '  '' 

was  deleted.  This  does  net  mean  that  one  cannot  request  a  specific 
change  or  an  addition  of  one  data  item  to  a  store J  activity. 

Limited  changes,  such  as  a  one -for -one  change,  an  addition  of  one 
scarce  reference,  or  addition  of  a  special  tool  to  an  activity  could  be 
requested  on  the  BTDS-G-GRAM.  BTDS  Control  translated  the  request 
to  a  DELETE  command  for  the  specified  activity,  requested  the  ap¬ 
propriate  data  cards  to  be  keypunched,  inserted  the  updated  data  cards 
'■*  -VsRP  *  /t 

in  *i»e  MADS  card  deck,  and  requested  a  STORE  command  to  enter  the 


updated  activity. 

"  -  • 


vigarge  changes  (more  than  five  specific  items)  required  new  MADS. 
BTDS  Control  had  the  new  form  keypunched,  DELETED  the  old  activity 
and  STORED  the  new  data. 

The  command  that  generated  a  deletion  was 

DELETE  (AWS)  (A CODE  -  X) 


where  •’X"  is  any  10-digit  activity  code. 

Examples  of  DELETE  and  CHANGE  requests  and  computer  responses 
are  shown  in  Figure  3-8. 


iXES 


The  BTDS  Program  would  initiate  a  search  of  its  data  files  to  find  all 
items  which  satisfy  specified  conditions  upon  receipt  of  a  Query  com¬ 
mand,  The  BTDS  Program  responded  to  queries  by  printing  a  list  of 
all  activity  codes  and  their  relative  frame  numbers  applicable  to  the 
specified  parameter.  The  BTDS  Program  expected  a  complete  and 
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Figure  3-6  Examples  of  DELETE  and  CHANGE  Requests 


3-15 


Voi.  8 


Mn _ a 

HWC  TWI 


•m-o-«a*8i 


ttwcnneMMHMMM  »  tume  mmh  k .  - 

i  atom,  twtv*  w  «orr  ro  w  «  man  ottM  - ...  , — - — — [■ — .... 

trwK  ttaracio  MTaunM  »  raw  uh  ••iim  j  I -rut  *‘T*m 

•n.MrMnaHHN  i  »*■*»»»  t  »«"».> 

•»  i  >  onoTci  *  ¥wmr  jwmwmiom  mu  m  nmn i 

W  W  MMOTtS  A  VMMH(  MKWttWiOM  A*  MU  «®  ITS  MUI  at  MMB  •  * .  %y,  ■  f 

«•  #  *"*  “**»•*  «*>0*  fit  «*  ««g  LON  TM>  M»  ua  X  **.*  mm  a*V  nsj.8*  hum  *  MW'  WtaWJII!  «jr  T**e  TM  Bttt 

»««•«•  «»**«  «  n*  MEsn  UN  or  m*M  hk  ems  am  *<ecmv)  woiwt  tnc  mo  m 


* 

:  A 


••  ,  ^-  -r 


•*UM 

■•Ml 

»*7W 

t-njrmt 

8TDS~0’GMI£ 


WSW«  TWI 


2  twe  S  Aft*  WWHWWH  «  Kim  MMH 

i  stone  status  iii  larr  ro  w  •  «**r  iihh 

*TO#f  STATUS  «»»  NTAUIDIO  f  HW  l»W 

«  CM MH  1*1  WHM  •  AMO  iCTwmm  MUM 


•  »RW  iKWf  ttT*» 

f  »AW  0  |  *«AU*w*  3 


g 

vW: 


••ore 

•>  l)  DvMCTd  A  VNMAtlK  Off  WWW  MU  m  m MU 

fc<  W  DfMOTC*  A  V*4**«K.f  KSSf*K4T«0M  At  MU  tf  ITS  MUS  «  KMKI 

cl  lA  TM  KIUM  CAMM3T  MT  W  OM  l«  TWM  (HI  CAM  OK  **UT  ■IT'»!W  AM  HKltS  MUOMS  A  MKT  IMKIIWI  AMO  TMCM  TMf  MSt 
•*  0«T*  CAM  *MM  AS  TM  SCOOMO  UW  Or  KKWWS  TM  MOM  MTTB  Af&fT)  PMOC3IOM  TM  MMAEO  00» 

—  ■  »'  "  -  - . .  '  'uinaawppiww  a  a  an.  i  l  ■  '<»■'>  .  ■>  i  i  >  |  a  |  i  y  ■«■  ■■■■■■«  ■  im  iiiiiii  fT*'"  l"1""  T  ?  »«—■»'—<"  »V 

■  1  n  t  ■  n  o  i  iin  n»n  »  <  s|s  i  s  t»'  »  » -fji.r  i  vim  »  »  i  a|>  t  rit w >;i  »iA  t  t  >  r|oi»|ii 

•-  *  •'  •  •  -J .  *•**♦?♦ . .•*•••  li  •  »  •  1  ♦  UHJ  •  *  •  iatXl  iTi.i  l  t  1  jl  »  i  t  III  J  •  ♦  t  I  ♦] 


M}l 

&***>  (tps) vttH*  < ' 1 
^  Crpe)6^»c-/yt)f  ~y,  An  7 '  > »©» oi(  ’  ] ,  * ; 

. . i . , !  ,  j  i  ..11  . 1 .  | 

•  ( ;  » j  1  1  ■  j  . ;  j 

a** 'fr+t/afri***, M<?jo/oo/oo j |  ; ; ' ; j 

. .  j  I  j  •  ci.t 

ill  ,  1  1  'hi!'  :  ! 


CHANGE  REQUEST 


anted  th*  querying  of  the  BTDS  Program  for  information  to 


Initiates  a  transfer  to  the  query  program  and  must 


exis*  COTfflwd  before  initiating  action;  any  portion  left  out  or  improperly 
Mgtten  resulted  in  a  diagnostic  message  and  wasted  command. 


the  extant  and  impact  of  a  particular  source  reference 


(A  CODE) 

KD  [STY! 

{  FNO  ) 

rzmr  *u)  [pend-  « v) 


[STYPE  «  x )  <SNO  =  y) 


be  presert  for  all  quei*y  results. 


CODE) 


The  first  parameter  indicates  whether  relative 
frame  numbers  {FNO)  or  activity  codes  only 
(ACOD1S)  arc  desired. 


m- 


These  are: 


IPB 


yf  jjy 


EDO 


PIC 


The  fourth  parameter  indicates  the  point  at  which 
the  source  reference  begins. 


The  second  parameter  indicates  the  type  of  source 
file  to  l«e  searched,  "x"  may  be  any  of  the  source 
types  used  on  the  Maintenance  Activity  Data  Sheets 
(MADS) 


The  third  parameter  indicates  the  source  document 
I.D.  number. 


3-ie 


(PEND  *  v) 


The  last  parameter  indicates  the  point  at  which  the 
source  reference  ends. 

are  written  ia  the  same  format  as  for  MADS  input. 


The  span  of  paragraphs  "u"  and  "v"  is  unlimited.  ’V  eats  be  the  first 

;}  "  § 

paragraph  of  an  engineering  report  and  'V*  the  last  paragraph  of  the 
manual.  If  only  one  paragraph  or  figure  is  desired,  "u"  and  "v"  are 
identical.  '■  ? 

Examples  of  SOURCE  QUERY  requests  and  computer  responses  art? 
shown  in  Figures  3-7  and  3-8. 


2.  Query  on  Tool  Data 


This  represented  querying  the  BTDS  Program  for  activities  and  frames 
within  an  activity  that  referenced  a  particular  tool. 


The  command  was 


(ACODE) 


(TTYPE  *  x)  (TNO  *  y) 


FIND 


(ACODE) 
(  FNO  ) 


The  first  parameter  indicates  whether  relative 
frame  numbers  (FNO)  or  activity  codes  only 
(ACCDE)  are  desired. 


The  second  parameter  indicates  the  type  of  tool 
file  to  be  searched,  "x"  may  be  any  of  the  tool 
types  used  on  the  Maintenance  Activity  Data  Sheet 
(MADS).  These  are: 


The  last  parameter  indicates  the  tool  identification 
number. 
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Figure  3-8  Sample  Computer  Outputs  of  SOURCE 
QUERY  Requests 


Examples  ot  TOOL  QUERY  requests  and  computer  responses  are  shown 
in  Figures  3-9  and  3-10. 

3,  Query  c?i  Equipment  Part  Numbers 


This  represented  querying  the  BTOS  for  data  references  of  system  equip 

min*.  The  BTDS  Program  listed  all  activities  and  related  frames  that 

■ 

ware  formatted  against  a  particular  piece  of  equipment. 


(A  CODE) 


CEPNO  «  x) 


FIND 


(ACODE) 


The  first  parameter  indicates  whether  relative 
frame  numbers  (FNQ)  or  activity  codes  only 
(ACODE)  are  desired. 


(EPNO  =  x) 


The  last  parameter  indicates  the  equipment  part 
identification  number. 


Usually,  when  Change  Control  personnel  required  information  concern- 
ing  a  piece  of  aircraft  equipment,  it  was  desirable  to  know  not  only  the 
technical  data  referencing  the  equipment,  but  data  that  were  dependent 
on  the  equipment  in  some  manner.  This  information  cculd  be  obtained 
with  a  second  command  which  determined  if  the  equipment  had  been 
referenced  as  sn  EThDU  on  Maintenance  Activity  Data  Sheet  'MADS). 


The  command  was 


FIND  (ACODE)  (STADU  «  x) 


(ACODE) 


Note  that  th~  first  parameter  has  only  one  value 
(ACODE). 


(ETADU  =  x) 


The  last  parameter  indicates  the  equipment  part 
identification  number. 
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tigure  3-10  Semple  Computer  Outputs  for  TOOL  QUERY  Request 


Examples  of  EPNO  and  ETADU  QUERY  requests  and  computer  re 
sponges  are  shown  in  Figures  3-11  and  3“12. 


This  represented  querying  the  BTDS  for  references  of  a  particular 
activity  code.  This  command  did  not  print  a  list  of  activity  codes  that 
were  present  in  the  system  or  a  printed  image  of  Maintenance  Activity 
Data  Sheet  (MADS).  These  requests  were  accomplished  with  PRINT 
commands.  This  command  initiated  a  search  to  locate  and  print  other 
technical  data  segments  that  had  incorporated  this  data  in  their  respec¬ 
tive  format.  ■ 


FIND  (ACODE)  (INCA  =  x) 


(ACODE) 


Note  that  first  parameter  has  only  one  value 
(ACODE). 


(INCA  -  x) 


The  last  parameter  indicates  the  activity  code 
where  "x”  must  be  the  full  10-digit  ACODE. 


Examples  of  INCA  QUERY  requests  and  computer  response  are  shown 
in  Figures  3-13  and  3-14. 


G.  DIAGNOSTIC  MESSAGES 


The  BTDS  Program  included  various  diagnostic  routines  for  checking 
the  mechanical  validity  of  data  and  the  logical  and/or  content  validity  of 
data  requests.  Error  messages  which  attempted  to  clearly  identify  the 
trouble  were  printed  to  facilitate  the  rectification  of  errors. 


The  following  list  contains  the  err  or  messages  generated  by  the  BTDS 
Program  and  their  explanations.  Words  on  a  message  that  had  to  vary 
from  situation  to  situation  are  denoted  by  "a***". 
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Figure  3-11  Example  of  EPNO  and  ETADU  QUERY  Request 


i'iffure  3-12  Sample  Computer  Outputs  of  ICPNO  and 
KTADU  Request 
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Figure  3-14  Sample  Computer  Output  of  INCA  QUERY  Request 
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ERROR  — 

Hetc: 


THIS  ACTIVITY  IS  ALREADY  STORED  IN  THE  BTDS 
SYSTEM.  EITHER  DELETE  THE  PRESENT  ACTIVITY 
OR  RE-ENTER  THE  ACTIVITY  WITH  CORRECT  CODE. 

ACODE  * 

MBBBgFfefcr-  -*:■ 

(This  error  message  will  occur  if  a  MADS  has  already  been 
stored  in  the  data  files  for  the  same  activity  code  as  the 
attempted  STORE. ) 

THIS  ACTIVITY  IS  NOT  PRESENT  IN  THE  BTDS  SYS¬ 
TEM. 

ACODE  *  •*** 

(This  error  message  indicates  a  PRINT  request  for  an 
activity  that  is  not  present  in  the  system. ) 

BAD  COMMAND.  THIS  MAY  CAUSE  A  NUMBER  OF 
BAD  COMMANDS  TO  BE  PRINTED. 

BAD  COMMAND  =•***»  FROM  CARD  •*******• 

(This  error  message  will  occur  anytime  a  data  card  is  not 
standard  to  the  BTDS  input  format.  If  the  correct  command 
should  have  been  STORE  (AWS)  and  was  improperly  key¬ 
punched,  there  will  be  a  sequence  of  bad  commands,  one 
for  each  card  in  the  activity.  This  is  caused  by  the  BTDS 
interpreting  each  card  in  succession  in  search  of  a  legal 
command.  No  action  is  performed  on  this  command. ) 

■  THIS  BTDS  REQUEST  IS  OUT  OF  SEQUENCE  -  WOULD 
REQUIRE  REWINDING  ALL  SYSTEM  TAPES  REQUEST 
IGNORED. 

*#$• 

(This  error  message  indicates  that  data  has  been  mis- 
arranged  --  concerns  BTDS  control  only;  '**'  would  indicate 
the  ignored  request. ) 


_  Hu?  v  >  ' 


iyisA  ■ 


,  ••  •  V.  ■  v  ■  ,r  .  r 

\  -  •;  ?■'  .<  S  *  Z’<;  '  ?  *•  N-  •  •  -  • 


’  ft 

r*-.,  -  £ 

■BHi 


&  ..  fc  '•  ' 

*  Q  - 


•  ,< 


i.;;: 

►  i 


m 


ERROR  --  THIS  ACTIVITY  HAS  EXCEEDED  THE  LIMIT  ON  '**• 
INFORMATION. 

* 

ACODE  *  »***' 

(This  error  message  indicates  that  a  parameter  on  data 
information  has  been  exceeded.  Tue  information  may  be 
SOURCE,  TOOL,  INCA,  ETADU,  or  EPNO  inputs.  The 
quantity  of  the  specified  information  has  either  been  ln~ 

correctly  stated  on  the  Maintenance  Activity  Data  Sheet 

’’ 

(MADS)  or  improperly  3y punched.  No  action  is  performed 
on  this  activity. ) 

TAPE  ERRORS  —  FILES  NOT  AVAILABLE 

(This  error  message  indicates  that  incorrect  data  files 
were  mounted  at  the  computer  facility. ) 


PRODUCTION  CONTROL  PROGRAM 


The  Production  Control  (STATUS)  Programs  are  the  portion  of  the  BTDS 
System  which  provided  production  status  information.  This  program 
though  used  throughout  the  technical  data  production  phases  was  capable 
of  handling  change  or  revision  status  at  the  maintenance  segment  level. 
The  program  used  inputs  from  production  stations  (illustration,  typing, 
editing,  Q.  C. )  to  monitor  the  over-all  production  loop  with  reference  to 
each  segment  or  segment  groups  of  the  technical  data.  The  information 
provided  by  this  program  was  the  following: 


Identification  of  all  the  maintenance  information  in  each 
production  station. 


Information  as  to  the  output  of  each  production  station 


Over -all  production  status  of  each  group  of  maintenance  data. 

Information  as  to  the  number  of  loops  each  package  has  gone 
through  in  any  station  in  the  production  loop. 


Using  the  inf-  ^ation  supplied  by  the  STATUS  programs,  production 
managemen.  3onnel  could  evaluate  the  effectiveness  of  each  of  the 
stations  in  the  production  loop  while  also  scheduling  the  over -all 
technical  data  production  program. 


The  STATUS  program  was  used  during  PIMO  to  supply  the  production 
status  of  the  technical  data  to  management,  and  to  supply  this  infor¬ 
mation  both  from  the  standpoint  of  technical  data  requirements  aad 
the  production  station.  This  enabled  management  to  allocate  resources 
to  those  production  stations  most  requiring  it.  Furthermore,  these 
programs  provided  the  information  for  evaluation  of  the  over-all 


N 

\ 


production  flow  of  the  data  as  compared  with  the  scheduled  flow. 

B.  PURPOSE 

The  Production  Control  (STATUS)  Program?  were  designed  to  enable  a 
monitoring  of  the  production  and  status  of  a  technical  publications 
,  process.  They  were  successfully  used  during  PIMO  for  this  purpose. 

The  status  program  outputs  consisted  of  a  series  of  computer  tab  runs 
which  periodically  listed  the  activity  status  and  the  production  status. 
The  tab  runs  were  updated  weekly.  The  purposes  of  the  status  program 
outputs  were  to  provide: 

1.  The  location  of  any  activity  package  in  the  technical  publication 
process. 

2.  A  history  of  the  technical  publication  functions  and  correspond¬ 
ingly,  .  the  length  of  time  in  functions  performed  on  each 
individual  activity  package. 

3.  The  status  of  the  recent  and  over -all  production  rate  of  each 
station  (i.e. ,  illustration,  typing,  editing,  Q. C. )  in  the  tech¬ 
nical  publication  process. 

4.  The  status  of  the  number  of  activity  packages  either  queued  or 
in  process  at  each  station. 

5.  The  average  performance  time  in  each  station  and  the  average 
number  of  times  an  activity  package  had  to  be  "reworked"  in  a 
station. 

6.  The  over-all  production  status  of  the  total  effort  (percent 
completed). 

C.  RESULTS 

1.  Current  Activity  Status 


/ 


Vol.8 


4-2 


V-  ■ 
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The  activity  package  history  data  including  the  number  of  times  in  each 
station,  the  total  elapsed  time  in  each  station,  and  the  station  last  left 
and  last  entered,  allowed  the  review  of  possible  areas  for  an  activity 
package.  This  tab  run  was  designed  to  be  critically  reviewed  on  a 
weekly  basis  in  order  to  identify  possible  problem  areas  in  their  initial 
stages.  Some  of  the  problems  it  was  capable  of  identifying  were: 


The  first  STATUS  Program  output  was  the  Current  Activity  Status 
which  is  shown  in  Figure  4-1.  (See  Appendix  II  for  details  on  how  to 
read  the  Current  Activity  Status  printout.)  This  tab  run  listed  for  each 
activity  the  current  location  within  the  technical  publications  process  by 
station  (station  codes  are  noted  on  the  Flow  Chart  in  Figure  4-2)  and 
the  past  history  of  that  activity  in  addition  to  other  status  information. 
The  location  data  enables  the  rapid  location  of  any  activity  package. 

This  report  was  prepared  weekly;  therefore,  when  attempting  to  locate 
an  activity  package,  it  was  possible  that  it  had  moved  on  to  a  subsequent 
station.  If  this  was  the  case,  the  activity  package  could  be  easily  traced 
by  a  review  of  the  activity  status  updating  form  (Figure  4-3  --  Source 
of  Data  Input  to  the  STATUS  Program)  at  the  station  it  was  last  in  and 
following  the  stations  until  it  was  found.  : 


Activity  packages  being  queued  at  the  entrance  to  any 
station. 


Production  time  in  any  station  exceeding  the  expected 
production  time. 


Activity  packages  looping  back  to  be  reworked  by  any 
station. 


rI  he  purpose  of  the  evaluation  features  of  the  program  was  not  to  exer¬ 
cise  rigid  production  controls  on  the  stations,  but  rather  to  identify  the 
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Figure  4-1  Current  Activity  Status 
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problems  being  encountered  in  the  process,  thereby  allowing  an  early 
solution  to  alleviate  the  problems. 

2.  Number  of  Activities  Accomplished  Since  Last  Report 

This  tab  run,  shown  in  Figure  4-4,  reported  for  each  system,  priority, 
and  total  systems  ‘ha  number  of  activity  packages  accomplished  by  each 
station  since  the  last  report  (weekly).  The  activities  accomplished  were 
reported  t>y: 

1)  The  initial  time  accomplished  or  a  repeat  (rework)  time 
accomplished. 

2)  Whether  the  activity  packages  ‘were  accomplished  prior 
to  or  subsequent  to  the  verification  function. 

3)  Total  number  of  activity  packages  and  number  of  frames 
in  the  activity  packages  accomplished. 

This  tab  run  contained  many  of  the  problem  identification  features  men¬ 
tioned  for  the  previous  tab  run;  however,  the  analysis  was  done  at  a 
grosser  level  --by  system,  priority,  or  all  systems. 

3.  Number  of  Activities  Accomplished  to  Date. 

This  tab  run,  shown  in  Figure  4-5  is  identical  to  the  previous  tab  run 
with  the  exception  that  the  data  were  cumulative  from  the  beginning  of 
the  technical  publications  process  rather  than  just  from  the  previous 
update  of  the  STATUS  Program. 

This,  report  allowed  an  evaluation  of  the  over-all  production  status  or 
the  percent  of  total  effort  completed  by  system,  priority,  and  total 
systems. 

4.  Number  of  Activities  in  Process  by  Station 

This  tab  run,  shown  in  Figure  4-6  identified  the  number  of  activities 
either  queued  at  the  entrance  to  or  in  process  for  each  station. 


4-7 


Vol.  8 


Figure  4-4  Number  of  Activities  Accomplished  Since  Last  Report 
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Figure  4-5  Number  of  Activities  Accomplished  To  Date 


Figure  4-6  Number  of  Activities  in  Process  by  Station 
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This  tab  run  was  designed  to  allow  the  early  identification  of  "bottle¬ 
necks"  in  the  technical  publication  process. 


5.  Average  Performance  Data  on  Completed  Activities  by  Station 

This  tab  run,  shown  in  Figure  4-7  summarized  the  station  performance 
data  for  those  activities  that  had  been  completed.  The  average  time  in 
each  station  and  the  average  number  of  times  in  each  station  were  listed 
by  system,  priority,  and  total  systems. 

6.  Progress  Status  of  Activities 

This  tab  run,  shown  in  Figure  4-8,  listed  the  gross  production  status. 
Combined  with  Figure  4-9,  it  enabled  an  evaluation  of  the  percent  of 
total  effort  accomplished. 

D.  SPECIFICATIONS 

1.  Program 

The  technical  data  production  control  status  monitor  consisted  of  five 
computer  prog r^  ns  written  in  7094  COBOL.  A  brief  discuesion  of  the 
programs  is  given  below. 

a.  Status  -  1:  Periodically  updated  the  technical  data  control 
status  by  accepting  data  segment  change  of  status  instructions. 
Printed  out  the  present  status  and  past  history  of  each  data  pack¬ 
age.  Also  output  an  updated  data  segment  file. 

b.  Status  -  2:  Accepted  the  output  of  Status -1  and  updated  the 
status  summary  files.  Printed  out  summary  data  on  the  over-all 
status  and  the  status  and  production  of  each  station  in  the  technical 
data  control  process. 

c.  Change:  Accepted  change  instructions  to  add,  delete,  or 
change  any  activity  in  the  function-by-end -item  matrix;  change 

in  the  history  or  status  of  any  activity  due  to  the  input  or  erroneous 
change  of  status  cards. 
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Figure  4-7  Average  Performance  Data  on  Completed 
Activities  by  Station 
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d.  Print:  Printed  the  fun ction-by -end -item  matrix  from  the 
latest  activity  file.  Also  summarized  the  function -by-end -item 
matrix  by  system. 


e.  Load:  Initially  accepted  the  function-by-end -item  matrix 
in  order  to  set  up  the  activity  files.  Also  set  up  and  Initiated  the 
status  summary  files. 


Execution 


With  the  exception  of  LOAD,  these  programs  were  designed  to  be  stacked 
The  stacking  order  was  CHANGE,  STATUS-1,  STATUS-2,  and  PRINT. 
If  it  was  not  necessary  to  run  CHANGE  and/or  PRINT,  they  cou'd  be 
eliminated  from  the  run. 


The  latest  status  and  past  history  of  transactions  of  activity  paclcages 
and  the  status  summary  files  were  maintained  on  magnetic  tape  ;md 
updated  periodically.  This  tape  was  called  the  Master  Activity  File. 
The  tape  output  of  the  last  series  of  status  runs  was  considered  to  be 
the  New  Master  Activity  File  until  the  computer  preparations  were  ini 
tiated  for  the  next  run,  when  it  became  the  Old  Master  Activity  File. 


E.  DOCUMENTATION  PROCEDURES 


As  the  activity  packages  went  through  the  technical  data  control  system 
they  passed  through  a  number  of  stations  (or  functions)  as  depicted  by 
Figure  4-2.  Each  time  an  activity  left  one  of  these  stations,  the  trans¬ 
action  was  recorded  on  the  activity  status  updating  form  (Figure  4-3). 
The  activity  code  of  the  activity  package,  leaving  the  station  to  be  en¬ 
tered,  the  date,  and  sometimes  the  number  of  frames  (pages)  in  that 
activity,  were  entered. 


The  activity  status  updating  forms  were  periodically  keypunched  and  the 
cards  used  as  input  to  Status- 1.  Status -1  required  that  the  activity  flow 
be  sequential  (an  activity  package  could  not  ieave  a  station  without  first 
entering  that  station).  If  such  an  error  was  found,  Status- 1  printed  out 


an  error  message  identifying  the  problem  and  skipped  the  change  of 
status  instruction.  It  was  then  necessary  to  correct  the  error  and  re 
submit  the  skipped  instructions  in  the  next  periodic  run. 


a.  Input  The  function-by-end -item  matrix  was  inputted  in  the 
following  punched  card  format: 


1-48  Activity  nomenclature 

49-54  End  item  number  (first  of  6  digits  of  the 
activity  number) 

65-66  System  Operational  Check  formatting  code 

67-88  Troubleshoot  System  formatting  code 

89-70  Troubleshoot  Unit  formatting  code 

71-72  Remove  formatting  code 

73-74  Install  formatting  code 

75-76  Adjust  formatting  code 

77-18  Inspect  formatting  code 

79-80  Calibrate  formatting  code 


Also,  a  PIMO  date  Look-up  Table  was  inserted.  The  PIMO  date  is  a 
Julian  date  with  each  working  day  numbered  sequentially  from  a  set 
date.  The  Look-up  Table  enabled  the  conversion  from  calendar  dates 
to  the  PIMO  date  which  was  used  in  later  calculations.  Input  format 
was  on  punched  cards  with  each  card  having  15  fields  of  three  columns 
each.  These  values  were  stored  in  a  two-dimensional  matrix  with  the 
axis  corresponding  to  the  month  and  day  number. 


b.  Output.  New  Master  Activity  File  containing 


The  PIMO  calendar  matrix. 

The  initialized  activity  files. 

The  initialized  status  summary  files 


2.  Status  -  1 


(1)  Activity  status  update  cards.  For  format  see 
Figure  4-3. 

(2)  Old  Master  Activity  File. 


b.  Output 


(1)  New  Master  Activity  File  (without  updated  status 
summary  files). 


Listing  of  each  activity,  its  current  status  and 
past  history.  Figure  4-1  shows  a  sample  output 


Status  -  2 


Input.  New  Master  Activity  File  created  as  an  output  of 


Status  -  1 


b.  Output 


(1)  New  Master  Activity  File  (with  updated  status  sum 
mary  files). 


Five  summary  tables  as  described  below 


(a)  Number  of  Activities  Accomplished  Since  Last 
Report  (Figure  4-4),  This  report  showed  by  system 
and  by  priority  group  for  all  the  data,  the  number  of 
activity  package  transactions  made  since  the  laBt 


periodic  update  by  station.  A  description  of  the  rows 
are  as  follows: 


0  Initial  -  indicates  the  number  of  activity  packages 
going  through  that  station  for  the  first  time. 

®  Repeat  *  indicates  the  number  of  activity  packages 
being  reworked  by  that  station. 

6  Pre-vr  -  indicates  the  number  of  activity  packages 
going  through  that  station  before  they  went  through 
the  verification  function. 

•  Po-ver  -  indicates  the  number  of  activity  packages 
going  through  that  station  after  they  went  through 
the  verification  function. 

#  Total  -  total  activity  packages  going  through  that 
station. 

®  Frames  -  total  frames  (pages)  included  in  the  ac¬ 
tivity  packages  going  through  that  station. 

(b)  Number  of  Activities  Accomplished  to  Date 
(Figure  4-5).  Identical  to  the  above  except  the  time 
period  is  since  the  beginning  of  the  technical  data 
control  process. 

(c)  Number  of  Activities  in  Process  by  Station 
(Figure  4-6).  Indicates  the  number  of  activity  pack¬ 
ages  hi  that  station  as  of  the  periodic  cut-off  date. 

(d)  Average  Performance  Data  on  Completed  Ac¬ 
tivities  by  Station  (Figure  4-7).  For  all  completed 
activity  packages,  this  report  indicates  the  average 
time  Sind  the  average  number  of  times  spent  in  each 
station. 


(e)  Progress  Status  of  Activities  (Figure  4-3).  In¬ 
dicates  the  total  number,  number  not  begun,  number 
in  process,  number  completed,  frames  in  process, 
frames  completed,  and  average  time  in  system  of  com¬ 
pleted  activities  for  all  those  activities  requiring  re¬ 
formatting  as  shown  in  the  function-by-end -item  matrix. 


Print 

a.  Input.  New  Master  Activity  File. 

fc.  Output.  Listing  of  activities  in  the  functlon-by-end-item 
matrix  and  a  summary  of  the  formatting  codes  in  the  function-by¬ 
end-item  matrix.  Sample  outputs  are  shown  in  Figures  3-2  and 
4-9. 

Change 

a.  Input 

(1)  Old  (or  New)  Master  Activity  File, 

(2)  Change  instructions  in  punch  card  format.  Three 
command  instructions  can  be  input;  they  are  ADD, 
DELETE,  or  CHANGE.  The  ADD  command  will  add 
in  the  entire  file  for  an  end  item.  DELETE  will  elim- 
inate  an  entire  file  for  an  end  item.  CHANGE  will 
change  any  data  item  in  any  end  item  file  or  in  any  of 
the  summary  files. 

b.  Output 

(1)  Old  (or  New)  Master  Activity  File  (with  changes  made). 

(2)  Listing  of  changes  made  to  the  activity  files.  The 
example  output  is  shown  in  Figure  4-10. 


The  system  and  program  flowcharts  for  the  production  status  con 
trol  program  can  be  found  in  Appendix  I  of  this  volume. 
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APPENDIX  I 


BTDS  PROGRAM  AND  SYSTEM  FLOWCHARTS 


On  the  following  pages  are  the  System  and  Program  Flowcharts  for 
the  Easic  Technical  Data  Storage  and  Retrieval  (BTDS)  Programs. 
Figures  1-1  through  1-4  depict  the  system  flow  for  various  commands 
peculiar  to  the  BTDS.  These  commands  include  data  input,  deletion, 
printout,  and  query.  Figures  1-5  through  1-7  illustrate  the  over-all 
computer  program  flow. 
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Figure  1-6  BTDS  Program  Flowchart  No,  2 
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Figure  1-7  BTDS  Program  Flowchart  No.  3 


APPENDIX  H 


CODES  USED  FOR  CURRENT  ACTIVITY  STATUS  PRINTOUT 

TV  current  activity  status  printout  can  be  read  quite  simply  If  one 
r  understands  the  basic  codes  and  entries.  The  basic  codes  and  en- 

;  tries  are  encircled  on  Figure  II— 1.  Definitions  for  the  codes  and 

entries  are  keyed  to  the  encirclul  items  as  listed  below: 

1.  Activity  code. 

2.  An  "X"  in  this  column  indicates  that  the  activity  has  been 
through  verification  (Station  3). 

3.  A  "Y"  in  this  column  indicates  that  the  activity  is  "frozen" 
(no  further  revisions  allowed). 

4.  An  "X"  in  this  column  indicates  that  the  activity  is  completed 
(it  Has  reached  Stations  17,  18,  and  20). 

5.  Station  number  (see  the  reverse  side  of  Figure  4-3  for  the 
station  identifier). 

6.  Numbers  of  the  stations  where  the  activity  is  currently 
located. 

» 

7.  The  number  of  status  changes  for  that  activity  since  the 
last  status  run. 

8.  Error  code  which  indicates  an  activity  update  card  that 
had  an  activity  code  not  in  the  Old  Master  Activity  File. 

9.  Error  code  which  indicates  that  an  activity  update  card  has 
had  a  transaction  which  was  out  of  sequence  (the  update  card 
indicated  that  the  activity  left  Station  11  and  went  to  Station  1; 
hrwever,  the  Old  Master  Activity  File  had  the  location  of  the 
activity  as  being  in  Station  3). 


II- 1 


Vol.8 


Number  of  times  the  activity  has  been  in  that  station 


Elapsed  days  (not  including  the  current  time)  tbat  the  activity 
has  spent  in  that  station. 


The  PIMO  date  the  activity  lest  entered  or  left  that  station 
(if  the  activity  is  in  that  station,  it  is  the  date  last  entered 
if  the  activity  is  not  in  that  station,  it  is  the  date  la^t  left). 


PIMO  date  the  activity  entered  the  system 


PIMO  date  the  activity  entered  Station  17 


PIMO  date  the  activity  entered  Station  18 


PIMO  date  the  activity  entered  Station  20 


Number  of  frames  for  that  activity, 
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Figure  II- 1  Current  Activity  Status 
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